Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Message attachments #148

Open
wants to merge 18 commits into
base: main
Choose a base branch
from
Open

Conversation

brichet
Copy link
Collaborator

@brichet brichet commented Jan 17, 2025

Draft implementation of #147

EDIT:

Updating the screen-cast

record-2025-02-13_11.04.21.webm

There is now a lite deployment in the built doc including a simple extension with a chat panel. I updated it to allow attachments https://jupyter-chat--148.org.readthedocs.build/en/148/lite/lab/index.html

Copy link
Contributor

Binder 👈 Launch a Binder on branch brichet/jupyter-chat/message_attachments

@brichet brichet changed the title [WIP] message attachments Message attachments Jan 22, 2025
Copy link
Member

@dlqqq dlqqq left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@brichet Thank you for working on this while I was away! Left some feedback below.

packages/jupyter-chat/src/components/attachments.tsx Outdated Show resolved Hide resolved
packages/jupyter-chat/src/components/attachments.tsx Outdated Show resolved Hide resolved
Comment on lines +47 to +53
export interface IChatMessage<T = IUser, U = IAttachment> {
type: 'msg';
body: string;
id: string;
time: number;
sender: T;
attachments?: U[];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it make sense to type attachments as a generic type argument if we're providing an interface (IAttachment)? This allows any generic type U, including primitives like number or boolean which may not be handled by the backend.

I think it makes sense to require attachments to all be dictionaries and enforce an interface:

Suggested change
export interface IChatMessage<T = IUser, U = IAttachment> {
type: 'msg';
body: string;
id: string;
time: number;
sender: T;
attachments?: U[];
export interface IChatMessage<T = IUser> {
type: 'msg';
body: string;
id: string;
time: number;
sender: T;
attachments?: IAttachment[];

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This interface is reused in jupyterlab-chat packages with the IYmessage. In this case, it is only an id of an attachment (same as the users), to avoid saving several time the same attachment in the final document.

packages/jupyterlab-chat/src/model.ts Outdated Show resolved Hide resolved
packages/jupyter-chat/src/model.ts Outdated Show resolved Hide resolved
packages/jupyter-chat/src/model.ts Outdated Show resolved Hide resolved
packages/jupyter-chat/src/model.ts Outdated Show resolved Hide resolved
packages/jupyter-chat/src/model.ts Outdated Show resolved Hide resolved
@brichet
Copy link
Collaborator Author

brichet commented Feb 6, 2025

Thanks for the review @dlqqq, I addressed some of your comments. I'll take a look at an alternative to clickAttachments().

@brichet brichet force-pushed the message_attachments branch from 2658548 to f9f5a6b Compare February 12, 2025 15:35
/**
* A signal emitting when the input attachments changed.
*/
readonly inputAttachmentsChanges?: ISignal<IChatModel, IAttachment[]>;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe with the following spelling, similar to the names of other signals?

Suggested change
readonly inputAttachmentsChanges?: ISignal<IChatModel, IAttachment[]>;
readonly inputAttachmentsChanged?: ISignal<IChatModel, IAttachment[]>;

@brichet brichet marked this pull request as ready for review February 13, 2025 12:43
@brichet
Copy link
Collaborator Author

brichet commented Feb 13, 2025

The recurrent failing test do not fails locally. And strangely, it constantly fails at opening the chat, which is done in other tests with the same chat file...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants